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Abstract 


This document describes the interface to the Telnet server on IBM’s 
iSeries line of midrange business computers. This interface allows 
Telnet clients to request a Telnet terminal or printer session using 
specific session attributes related to device names, encryption, 
language support, auto-sign-on, response codes, session association, 
etc. 


These support functions are implemented primarily using the Telnet 


Environment option negotiation RFC 1572 to define new USERVAR 
variables that will be recognized by iSeries Telnet server. 
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1. Introduction 


The iSeries Telnet server enables clients to negotiate both terminal 
and printer device names through Telnet Environment Options 
Negotiations [RFC1572]. 


This allows Telnet servers and clients to exchange environment 
information using a set of standard or custom variables. By using a 
combination of both standard VARs and custom USERVARs, the iSeries 
Telnet server allows client Telnet to request a pre-defined specific 
device by name. 


If no pre-defined device exists, then the device will be created, 
with client Telnet having the option to negotiate device attributes, 
such as the code page, character set, keyboard type, etc. 


Since printers can now be negotiated as a device name, new terminal 
types have been defined to request printers. For example, you can 
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now negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE 
options [RFC1091]. 


Finally, the iSeries Telnet server will allow exchange of user 
profile and password information, where the password may be in either 
plain text or encrypted form. If a valid combination of profile and 
password is received, then the client is allowed to bypass the sign- 


on panel. The local server setting of the QRMTSIGN system value must 
be either *VERIFY or *SAMEPRF for the bypass of the sign-on panel to 
succeed. 


2. Standard Telnet Option Negotiation 


Telnet server option negotiation [RFC855] typically begins with the 
issuance, by the server, of an invitation to engage in terminal type 
negotiation with the Telnet client (DO TERMINAL-TYPE) [RFC1091]. The 
client and server then enter into a series of sub-negotiations to 
determine the level of terminal support that will be used. After the 
terminal type is agreed upon, the client and server will normally 
negotiate a required set of additional options (EOR [RFC885], BINARY 
[RFC856], SGA [RFC858]) that are required to support "transparent 
mode" or full screen 5250/3270 block mode support. As soon as the 
required options have been negotiated, the server will suspend 
further negotiations and begin with initializing the actual virtual 
device on the iSeries. A typical exchange might start as follows: 


iSeries Telnet server Enhanced Telnet client 
TAC DO TERMINAL-TYPE --> 

<-- TAC WILL TERMINAL-TYPE 
TAC SB TERMINAL-TYPE SEND 
IAC SE --> 

TAC SB TERMINAL-TYPE IS 

<-- IBM-5555-C01 IAC SE 
IAC DO EOR --> 

<-- IAC WILL EOR 

<-- IAC DO EOR 
TAC WILL EOR --> 


(other negotiations) 
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Actual bytes transmitted in the above example are shown in hex below. 


iSeries Telnet server Enhanced Telnet client 
FF FD 18 --> 

<-- FF FB 18 
FF FA 18 01 FF FO --> 


FF FA 18 00 49 42 4D 2D 
35: 39 35.39. .2D:°43-.30"-31: 


<-- FF FO 
FF FD 19 --> 
<-- FF FB 19 
<-- FF FD 19 
FF FB 19 --> 


(other negotiations) 


Some negotiations are symmetrical between client and server, and some 
are negotiated in one direction only. Also, it is permissible and 
common practice to bundle more than one response or request, or to 
combine a request with a response, so in practice the actual exchange 
may look different from what is shown above. 


3. Enhanced Telnet Option Negotiation 


In order to accommodate the new environment option negotiations, the 
server will bundle an environment option invitation along with the 
standard terminal type invitation request to the client. 


A client should either send a negative acknowledgment (WONT NEW- 
ENVIRON), or at some point after completing terminal-type 
negotiations, but before completing the full set of negotiations 
required for 5250 transparent mode, engage in environment option 
sub-negotiation with the server. A maximum of 1024 bytes of 
environment strings may be sent to the server. A recommended 
sequence might look like the following: 
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iSeries Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON 
IAC DO TERMINAL-TYPE --> 
(2 requests bundled) 
<-- IAC WILL NEW-ENVIRON 
IAC SB NEW-ENVIRON SEND 
VAR IAC SE --> 
IAC SB NEW-ENVIRON IS 
VAR "USER" VALUE "JONES" 
USERVAR "DEVNAME" 
VALUE "MYDEVICEO7" 
<-- IAC SE 
<-- IAC WILL TERMINAL-TYPE 
(do the terminal type 
sequence first) 
IAC SB TERMINAL-TYPE SEND 


IAC SE --> 
IAC SB TERMINAL-TYPE IS 
<-- TBM-5555-C01 IAC SE 
(terminal type negotiations 
completed) 
IAC DO EOR --> 
(server will continue 
with normal transparent 
mode negotiations) 
<-- IAC WILL EOR 


(other negotiations) 


Murphy, et al. Informational [Page 5] 


RFC 4777 IBM’s iSeries Telnet Enhancements November 2006 


Actual bytes transmitted in the above example are shown in hex below. 


iSeries Telnet server Enhanced Telnet client 
FF FD 27 
FF FD 18 --> 
(2 requests bundled) 
<-- FF FB 27 
FF FA 27 01 00 FF FO --> 


FF FA 27 00 00 55 53 45 
52 01 4A 4F 4E 45 53 03 
44 45 56 4E 41 4D 45 01 
4D 59 44 45 56 49 43 45 
<-- 30 37 FF FO 
<-- FF FB 18 
(do the terminal type 
sequence first) 


FF FA 18 01 FF FO --> 
FF FA 18 00 49 42 4D 2D 
35 35 35 35 2D 43 30 31 
<-- FF FO 
FF FD 19 --> 


(server will continue 
with normal transparent 
mode negotiations) 
<-- FF FB 19 


(other negotiations) 


Telnet environment options defines 6 standard VARs: USER, JOB, ACCT, 
PRINTER, SYSTEMTYPE, and DISPLAY. The USER standard VAR will hold 
the value of the iSeries user profile name to be used in auto-sign-on 
requests. The Telnet server will make no direct use of the 
additional 5 VARs, nor are any of them required to be sent. All 
standard VARs and their values that are received by the Telnet server 
will be placed in a buffer, along with any USERVARs received 
(described below), and made available to a registered initialization 
exit program to be used for any purpose desired. 


There are some reasons you may want to send NEW-ENVIRON negotiations 
prior to TERMINAL-TYPE negotiations. With an iSeries Telnet server, 
several virtual device modes can be negotiated: 1) VTxxx device, 2) 
3270 device, and 3) 5250 device (includes Network Station). The 
virtual device mode selected depends on the TERMINAL-TYPE negotiated 
plus any other Telnet option negotiations necessary to support those 
modes. The iSeries Telnet server will create the desired virtual 
device at the first opportunity it thinks it has all the requested 
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attributes needed to create the device. This can be as early as 
completion of the TERMINAL-TYPE negotiations. 


For the case of Transparent mode (5250 device), the moment TERMINAL- 
TYPE, BINARY, and EOR options are negotiated, the Telnet server will 
go create the virtual device. Receiving any NEW-ENVIRON negotiations 
after these option negotiations are complete will result in the NEW- 
ENVIRON negotiations having no effect on device attributes, as the 
virtual device will have already been created. 


So, for Transparent mode, NEW-ENVIRON negotiations are effectively 
closed once EOR is negotiated, since EOR is generally the last option 
done. 


For other devices modes (such as VTxxx or 3270), you cannot be sure 
when the iSeries Telnet server thinks it has all the attributes to 
create the device. Recall that NEW-ENVIRON negotiations are 
optional, and therefore the iSeries Telnet server need not wait for 
any NEW-ENVIRON options prior to creating the virtual device. It is 
in the clients’ best interest to send NEW-ENVIRON negotiations as 
soon as possible, preferably before TERMINAL-TYPE is negotiated. 
That way, the client can be sure that the requested attributes were 
received before the virtual device is created. 


4. Enhanced Display Emulation Support 


Telnet environment option USERVARs have been defined to allow a 
compliant Telnet client more control over the Telnet server virtual 
device on the iSeries and to provide information to the Telnet server 
about the client. These USERVARs allow the client Telnet to create 
or select a previously created virtual device. If the virtual device 
does not exist and must be created, then the USERVAR variables are 
used to create and initialize the device attributes. If the virtual 
device already exists, the device attributes are modified. 
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The USERVARsS defined to accomplish this are: 


USERVAR VALUE EXAMPLE DESCRIPTION 

DEVNAME us-ascii char (x) MYDEVICEO7 Display device name 

KBDTYPE us-ascii char (3) USB Keyboard type 

CODEPAGE us-ascii char (y) 437 Code page 

CHARSET us-ascii char (y) 1212 Character set 

IBMSENDCONFREC us-ascii char (3) YES | NO Startup Response 
Record desired 

IBMASSOCPRT us_ascii char (x) RFCPRT Printer associated 
with display 
device 


x - up to a maximum of 10 characters 
y - up to a maximum of 5 characters 


For a description of the KBDTYPE, CODEPAGE, and CHARSET parameters 
and their permissible values, refer to Chapter 8 in the 
Communications Configuration Reference [COMM-CONFIG] and also to 
Appendix C in National Language Support [NLS-SUPPORT]. 


The CODEPAGE and CHARSET USERVARs must be associated with a KBDTYPE 
USERVAR. If either CODEPAGE or CHARSET are sent without KBDTYPE, 
they will default to system values. A default value for KBDTYPE can 
be sent to force CODEPAGE and CHARSET values to be used. 


iSeries system objects such as device names, user profiles, plain 
text passwords, programs, libraries, etc., are required to be 
specified in English uppercase. This includes: 


any letter (A-Z), any number (0-9), special characters (# $ _ Q) 


Therefore, where us-ascii is specified for VAR or USERVAR values, it 
is recommended that uppercase ASCII values be sent, which will be 
converted to Extended Binary Coded Decimal Interchange Code (EBCDIC) 
by the Telnet server. 


A special case occurs for encrypted passwords (described in the next 
section), where both the initial password and user profile used to 
build the encrypted password must be EBCDIC English uppercase, in 
order to be properly authenticated by the Telnet server. 


The IBMASSOCPRT USERVAR is used to provide the device name of a 
printer that will be associated with the display device that is 
created. The device description of the printer name provided must 
currently exist on the Telnet server system. The IBMSENDCONFREC 
USERVAR is used by the enhanced Telnet client to inform the Telnet 
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server that a display Startup Response Record should be sent to the 


client. This record communicates the name of the actual display 
device acquired. If the attempt is unsuccessful, the reason code 
will be set to provide additional information on why the attempt 
failed. In addition to the device name and reason code, the Startup 


Response Record will contain the name of the Telnet server system. 


For more details on the Startup Response Record, see Section 11 of 
this document. 


5. Enhanced Display Auto-Sign-On and Password Encryption 


To allow password encryption, new IBMRSEED and IBMSUBSPW USERVARSs 
will be used to exchange seed and substitute passwords information. 
IBMRSEED will carry a random seed to be used in both the Data 
Encryption Standard (DES) and Secure Hash Algorithm (SHA) password 
encryption, and IBMSUBSPW will carry the encrypted copy of the 
password. 


The DES encryption would use the same 7-step DES-based password 
substitution scheme as APPC and Client Access. For a description of 


DES encryption, refer to Federal Information Processing Standards 
Publications (FIPS) 46-2 [FIPS-46-2] and 81 [FIPS-81]. 


The SHA encryption is described in Federal Information Processing 
Standards Publication 180-1 [FIPS-180-1]. 


The FIPS documents can be found at the Federal Information Processing 
Standards Publications link: 


http://www.itl.nist.gov/fipspubs/by-num.htm 


If encrypted password exchange is not required, plain text password 
exchange is permitted using the same USERVARs defined for encryption. 
For this case, the random client seed should be set either to an 
empty value (preferred method) or to hexadecimal zeros to indicate 
the password is not encrypted, but is plain text. 


It should be noted that security of plain text password exchange 
cannot be guaranteed unless the network is physically protected or a 
trusted network (such as an intranet). If your network is vulnerable 
to IP address spoofing or directly connected to the Internet, you 
should engage in encrypted password exchange to validate a client’s 
identity. 


Additional VARs and USERVARsS have also been defined to allow an 
auto-sign-on user greater control over their startup environment, 
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similar to what is supported using the Open Virtual Terminal 
(QTVOPNVT) API [SYSTEM-APT]. 

The standard VARS supported to accomplish this are: 
VAR VALUE EXAMPLE DESCRIPTION 
USER us-ascii char(x) USERXYZ Daet peilen 


x - up to a maximum of 10 characters 


The custom USERVARs defined to accomplish this are: 


USERVAR VALUE EXAMPLE DESCRIPTION 
IBMRSEED binary (8) 8-byte hex field Random client 
seed 
IBMSUBSPW binary (128) 128-byte hex field Substitute 
password 
IBMCURLIB us-ascii char (x) QGPL Current library 
IBMIMENU us-ascii char (x) MAIN Initial menu 
IBMPROGRAM us-ascii char (x) QCMD Program to call 


x - up to a maximum of 10 characters 


In order to communicate the server random seed value to the client, 
the server will request a USERVAR name made up of a fixed part (the 8 
characters "IBMRSEED") immediately followed by an 8-byte hexadecimal 
variable part, which is the server random seed. The client generates 
its own 8-byte random seed value and uses both seeds to encrypt the 
password. Both the encrypted password and the client random seed 
value are then sent to the server for authentication. Telnet 
environment option rules will need to be adhered to when transmitting 
the client random seed and substituted password values to the server. 
Specifically, since a typical environment string is a variable length 
hexadecimal field, the hexadecimal fields are required to be escaped 
and/or byte stuffed according to the RFC 854 [RFC854], where any 
single byte could be misconstrued as a Telnet IAC or other Telnet 
option negotiation control character. The client must escape and/or 
byte stuff any bytes that could be seen as a Telnet environment 
option, specifically VAR, VALUE, ESC, and USERVAR. 


If you use the IBMSENDCONFREC USERVAR, as described in Section 5 of 
this document, with a value of YES along with the automatic sign-on 
USERVARS described above, you will receive a Startup Response Record 
that will contain a response code informing your Telnet client of the 
success or failure of the automatic sign-on attempt. See Section 11 
of this document for details on the Startup Response Record. 
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The following illustrates the encrypted case: 


iSeries Telnet server Enhanced Telnet client 


IAC DO NEW-ENVIRON --> 
<-- IAC WILL NEW-ENVIRON 
IAC SB NEW-ENVIRON SEND 
USERVAR "IBMRSEEDXXXXXXXX" 
USERVAR "IBMSUBSPW" 


VAR USERVAR IAC SE --> 
IAC SB NEW-ENVIRON IS 
VAR "USER" VALUE "DUMMYUSR" 
USERVAR "IBMRSEED" VALUE "yyyyyyyy" 
USERVAR "IBMSUBSPW" VALUE "zzzzzzzz" 
<-- IAC SE 


(other negotiations) 


In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 
seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed, and 
"ZzZzzZzzzZzzzzZ" is an 8-byte hexadecimal encrypted password (if the DES 
encryption algorithm was used) or a 20-byte hexadecimal encrypted 
password (if the SHA encryption algorithm was used). If the password 
is not valid, then the sign-on panel is not bypassed. If the 
password is expired, then the sign-on panel is not bypassed. 


Actual bytes transmitted in the above example are shown in hex below, 
where the server seed is "7D3E488F18080404", the client seed is 
"4F4142334E414233", and the DES encrypted password is 
"DFBO402F22ABA3BA". The user profile used to generate the encrypted 
password is "44554D4D59555352" (DUMMYUSR), with a plain text password 
of "44554D4D595057" (DUMMYPW) . 
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iSeries Telnet server 


FF FD 27 


FF FA 
52 53 
8F 18 
4D 53 
00 FF 


27 
45 
08 
39) 
FO 


The following illustrates the plain 


iSeries Telnet server 


IAC DO NEW-ENVIRON 


IAC SB NEW-ENVIRON SEND 
USERVAR "IBMRSEEDXXXXXXXX" 
USERVAR "IBMSUBSPW" 

VAR USERVAR IAC SE 


(other negotiations) 
In this example, "xxxxxxxx" 
seed, and "yyyyyyyyyy" 
password. 
bypassed. 
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Enhanced Telnet client 


FF 
92 
53 
45 
4E 
53 
BO 
FO 


FA 
01 
52 
45 
41 
55 
40 


27 
44 
03 
44 
42 
42 
2F 


00 
55 
49 
01 
33 
53 
22 


00 
4D 
42 
4E 
03 
50 
AB 


59 
4D 
4D 
41 
49 
57 
A3 


53 
59 
52 
42 
42 
01 
BA 


45 
39 
53 
33 
4D 
DF 
FF 


text case: 


Enhanced Telnet client 


IAC WILL NEW-ENVIRON 


IAC SB NEW-ENVIRON IS 


VAR "USER" VALUE "DUMMYUSR" 

USERVAR "IBMRSEED" VALUE 

USERVAR "IBMSUBSPW" VALUE "yyyyyyyy" 
IAC SE 


is an 8-byte hexadecimal random server 


is a 128-byte us-ascii client plain text 
If the password has expired, then the sign-on panel is not 


Actual bytes transmitted in the above example are shown in hex below, 


where the server seed is 


"7D3E488F18080404", 


the client seed is 


empty, and the plain text password is "44554D4D595057" (DUMMYPW). 
The user profile used is "44554D4D59555352" (DUMMYUSR). 
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iSeries Telnet server Enhanced Telnet client 


FF FD 27 ==> 


FF FA 27 01 03 49 42 4D 
52 53 45 45 44 7D 3E 48 
8F 18 08 04 04 03 49 42 
4D 53 55 42 53 50 57 03 
00 FF FO --> 
FF FA 27 00 00 55 53 45 
52 01 44 55 4D 4D 59 55 
53 52 03 49 42 4D 52 53 
45 45 44 01 03 49 42 4D 
53 55 42 53 50 57 01 44 
<-- 55 4D 4D 59 50 57 FF FO 


5.1. Data Encryption Standard (DES) Password Substitutes 


Both APPC and Client Access use well-known DES encryption algorithms 
to create encrypted passwords. A Network Station or Enhanced Client 
can generate compatible encrypted passwords if it follows these 
steps, details of which can be found in the Federal Information 
Processing Standards 46-2 [FIPS-46-2]. 


1) Padded_PW = Left justified user password padded to the right with 
'40’X to 8 bytes. 


The user’s password must be left justified in an 8-byte variable 
and padded to the right with ’40’X up to an 8-byte length. If the 
user’s password is 8 bytes in length, no padding will occur. For 
computing password substitutes for passwords of length 9 and 10, 
see "Handling passwords of length 9 and 10" below. Passwords less 
than 1 byte or greater than 10 bytes in length are not valid. 
Please note that if password is not in EBCDIC, it must be 
converted to EBCDIC uppercase. 


2) XOR_PW = Padded_PW xor '5555555555555555’X 
The padded password is Exclusive OR’ed with 8 bytes of '55’X. 

3) SHIFT_RESULT = XOR_PW << 1 
The entire 8-byte result is shifted 1 bit to the left; the left- 
most bit value is discarded, and the rightmost bit value is 


cleared to 0. 


4) PW_TOKEN = DES_ECB_ mode (SHIFT_RESULT, lt key */ 
userID_in_EBCDIC_uppercase /* data */ ) 
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This shifted result is used as key to the Data Encryption Standard 
(Federal Information Processing Standards 46-2 [FIPS-46-2]) to 
encipher the user identifier. When the user identifier is less 
than 8 bytes, it is left justified in an 8-byte variable and 
padded to the right with ’40’X. When the user identifier is 9 or 
10 bytes, it is first padded to the right with ’40’X to a length 
of 10 bytes. Then bytes 9 and 10 are "folded" into bytes 1-8 
using the following algorithm: 


Bit 0 is the high-order bit (i.e., has value of ’80’X). 


Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1 
Exclusive OR’ed with byte 9, bits 0 and 1. 
Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1 
Exclusive OR’ed with byte 9, bits 2 and 3. 
Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1 
Exclusive OR’ed with byte 9, bits 4 and 5. 
Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1 
Exclusive OR’ed with byte 9, bits 6 and 7. 
Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1 
Exclusive OR’ed with byte 10, bits 0 and 1. 
Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1 
Exclusive OR’ed with byte 10, bits 2 and 3. 
Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1 
Exclusive OR’ed with byte 10, bits 4 and 5. 
Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1 
Exclusive OR’ed with byte 10, bits 6 and 7. 


User identifiers greater than 10 bytes or less than 1 byte are not 
the result of this encryption ID, known as PW_TOKEN in the paper. 


5) Increment PWSEQs and store it. 


Each LU must maintain a pair of sequence numbers for ATTACHs sent 
and received on each session. Each time an ATTACH is generated, 
(and password substitutes are in use on the session) the sending 
sequence number, PWSEQs, is incremented and saved for the next 
time. Both values are set to zero at BIND time. So the first use 
of PWSEQs has the value of 1 and increases by one with each use. 
A new field is added to the ATTACH to carry this sequence number. 
However, in certain error conditions, it is possible for the 
sending side to increment the sequence number, and the receiver 
may not increment it. When the sender sends a subsequent ATTACH, 
the receiver will detect a missing sequence. This is allowed. 
However the sequence number received must always be larger than 
the previous one, even if some are missing. 
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The maximum number of consecutive missing sequence numbers allowed 
is 16. If this is exceeded, the session is unbound with a 
protocol violation. 


Note: The sequence number must be incremented for every ATTACH 


sent. However, the sequence number field is only required to be 
included in the FMH5 if a password substitute is sent (byte 4, bit 
3 on). 


6) RDrSEQ = RDr + PWSEQs /* RDr is server seed. */ 


The current value of PWSEQs is added to RDr, the random value 
received from the partner LU on this session, yielding RDrSEQ, 
essentially a predictably modified value of the random value 
received from the partner LU at BIND time. 


7) PW_SUB = DES_CBC_mode (PW_TOKEN, /* key * / 
(RDrSEQ, /* 8 bytes */ 
RDs, /* 8 bytes */ 
ID xor RDrSEQ, /* 16 bytes */ 
PWSEQs, /* 8 bytes */ 
) /* data */ 


) 


The PW_TOKEN is used as a key to the DES function to generate an 
8-byte value for the following string of inputs. The DES CBC 
mode Initialization Vector (IV) used is 8 bytes of ’00’X. 


RDrSEQ: the random data value received from the partner LU 
plus the sequence number. 


RDs: the random data value sent to the partner LU on BIND 
for this session. 


A 16-byte value created by: 


-— padding the user identifier with '’40’X to a length 
of 16 bytes. 


- Exclusive OR’ing the two 8-byte halves of the padded 
user identifier with the RDrSEQ value. 


Note: User ID must first be converted to EBCDIC 
uppercase. 


PWSEQs: the sequence number. 
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This is similar to the process used on LU-LU verification as 
described in the Enhanced LU-LU Bind Security. The resulting 
enciphered random data is the ’password substitute’. 


8) Handling passwords of length 9 and 10 


1. Generate PW_TOKENa by using characters 1 to 8 of the password 
and steps 1-4 from the previous section. 


2. Generate PW_TOKENb by using characters 9 and 10 and steps 1-4 
from the previous section. In this case, Padded_PW from step 1 
will be characters 9 and 10 padded to the right with ’40’X, for 
a total length of 8. 


3. PW_TOKEN = PW_TOKENa xor PW_TOKENb 


4. Now compute PW_SUB by performing steps 5-7 from the previous 
section. 


9) Example DES Password Substitute Calculation 


ID: USER123 

Password: ABCDEFG 

Server seed: '7D4C2319F28004B2’X 

Client seed: /’O8BEF662D851F4B1’X 

PWSEQs: 1 (PWSEQs is a sequence number needed in the 
7-step encryption, and it is always one) 


DES Encrypted Password should be: /’ 5A58BD50E4DD9B5F’ X 
5.2. Secure Hash Algorithm (SHA) Password Substitutes 


A Network Station or Enhanced Client can generate SHA encrypted 
passwords if it follows these steps. 


1) Convert the user identifier to uppercase UNICODE format (if it is 
not already in this format). 


The user identifier must be left justified in a 10-byte variable 
and padded to the right with ’40’X up to a 10-byte length prior to 
converting it to UNICODE. If the user’s password is 10 bytes in 
length, no padding will occur. User identifiers of less than 1 
byte or greater than 10 bytes in length are not valid. The user 
identifier will be 20 bytes in length after conversion to UNICODE, 
so the variable that will hold the UNICODE user identifier should 
have a length of 20 bytes. 
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2) Ensure the password is in UNICODE format (if it is not already in 
this format). 


The user’s password must be left justified in a 128-byte variable. 
It does not need to be padded to the right with ’40’X up toa 
128-byte length. Passwords less than 1 byte or greater than 128 
bytes in length are not valid. The password will be 2 times its 
original length after conversion to UNICODE, so the maximum length 
of the variable that will hold the UNICODE password is 256 bytes. 


3) Create a 20-byte password token as follows: 


PW_token = SHA-1 (uppercase_unicode_userid, /* 20 bytes */ 
unicode_password) /* from 2 to 256 bytes */ 


The actual routine to be used to perform the SHA-1 processing is 
dependent on the programming language being used. For example, if 
using the Java language, then use the java.security class to 
perform the actual SHA-1 processing. 


The PW_token will be used in subsequent step to actually generate 
the final substitute password. 


4) Increment PWSEQs and store it. 


5) Create the 20-byte substitute password as follows: 


PW_SUB = SHA-1(PW_token, /* 20 bytes */ 
serverseed, /* 8 bytes */ 
clientseed, /* 8 bytes */ 
uppercase_unicode_userid, /* 20 bytes */ 
PWSEQ) /* 8 bytes */ 


The actual routine to be used to perform the SHA-1 processing is 
dependent on the programming language being used. For example, if 
using the Java language, then use the java.security class to 
perform the actual SHA-1 processing. 


6) Example SHA Password Substitute Calculation 


ID: USER123 

Password: AbCdEfGh123?+ 

Server seed: /’3E3A71C78795E5F5’X 

Client seed: ‘'’B1C806D5D377D994’X 

PWSEQs: 1 (PWSEQs is a sequence number needed in the 
SHA encryption, and it is always one) 
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SHA Encrypted Password should be: 
‘ET7FABSF034BEDA42E91F439DD07532A24140E3DD’ X 
6. Kerberos Services Ticket Automatic Sign-On Support 


An iSeries Telnet server specific USERVAR defined below will contain 
the complete Generic Security Services (GSS) token for use on the 
iSeries. Enhanced Telnet clients will need to obtain the Kerberos 
services ticket from a Key Distribution Center (KDC). Implementation 
steps for acquiring the Kerberos services ticket will be limited to 
the Microsoft Security Support Provider Interface (SSPI) example 
below. For information on Kerberos services tickets, refer to your 
Network Authentication Service (NAS) documentation. 


The custom USERVAR defined is: 

USERVAR VALUE EXAMPLE DESCRIPTION 

IBMPICKET binary (16384) 16384-byte hex field Kerberos services token 
Several other USERVARs, as defined in Section 6, can be used along 
with the IBMTICKET USERVAR to allow a user greater control over their 


startup environment. 


The custom USERVARs defined to accomplish this are: 


USERVAR VALUE EXAMPLE DESCRIPTION 
IBMCURLIB us-ascii char (x) QGPL Current library 
IBMIMENU us-ascii char (x) MAIN Initial menu 
IBMPROGRAM us-ascii char (x) QCMD Program to call 


x - up to a maximum of 10 characters 


If you use the IBMSENDCONFREC USERVAR, as described in Section 5, 
with a value of YES along with the Kerberos ticket USERVARs described 
above, you will receive a Startup Response Record that will contain a 
response code informing your Telnet client of the success or failure 
of the Kerberos validation attempt. See Section 11 for details on 
the Startup Response Record. 


The following Microsoft SSPI example illustrates how to get the 
client security token, which contains the Kerberos services ticket. 
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1) Get a handle to the user’s credentials: 
PSecurityFunctionTable pSSPI_; 
CredHandle credHandle; 


TimeStamp timeStamp; 


ss = pSSPI_->AcquireCredentialsHandle ( 


NULL, // Principal 
"Kerberos", // PackageName 
SECPKG_CRED_OUTBOUND, // CredentialUse 
NULL, // “LogonID 
NULL, // AuthData 
NULL, // GetKeyFnec 
NULL, // GetKeyArg 
&credHandle, // CredHandle 
&timeStamp) ; // ExpireTime 
2) Initialize security context to "request delegation". Mutual 


authentication is also requested, although it is not required and 
may not be performed. 


CtxtHandle newContext; 

unsigned long contextAttr; 

unsigned char token[16384] ; 

unsigned long tokenLen = sizeof (token); 

SecBuffer sbo = {tokenLen, SECBUFFER_TOKEN, token}; 
SecBufferDesc sbdo = {SECBUFFER_VERSION, 1, &sbo} 


pSSPI_->InitializeSecurityContext ( 
&credHandle, // CredHandle 
NULL, // Context 
"krbsrv400/fullyqualifiedLowerCaseSystemName", 
// ServicePrincipalName 
ISC_REQ_ CONNECTION | ISC_REQ_DELEGATE | ISC_REQ_MUTUAL_AUTH, 
// ContextRequest 


NULL, // Reserved 
SECURITY _NATIVE_DREP, // DataRep 
NULL, // Input 

NULL, // Reserved 
&newContext, // NewContext 
&sbdo, // Output 
&contextAttr, // ContextAttr 
&timeStamp) ; // ExpireTime 


3) Free the user credentials handle with FreeCredentialsHandle(). 


4) Send security token to Telnet Server (padded with escape 
characters). 
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The following illustrates the Kerberos Token Negotiation: 


iSeries Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON --> 

<-- TAC WILL NEW-ENVIRON 
TAC SB NEW-ENVIRON SEND 
USERVAR "IBMRSEEDXXXXXXXX" 


VAR USERVAR IAC SE --> 
IAC SB NEW-ENVIRON IS 
USERVAR "“IBMTICKET" VALUE 
iy Av Ay Ay Ay ay Ay Ay a 
<-- IAC SE 


(other negotiations) 


In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 
seed, and "zzzzzzzz..." is the complete Kerberos services token. LE 
the Kerberos services token is not valid, then the sign-on panel is 
not bypassed. It should be noted that for the Kerberos token a 
random server seed is not needed, although it will be sent by the 
Telnet Server. 


Actual bytes transmitted in the above example are shown in hex below, 
where the server seed is "7D3E488F18080404", and the Kerberos 
services token starts with "DFBO0402F22ABA3BA...". The complete 
Kerberos services token is not shown here, as the length of the token 
could be 16384 bytes and would make this document extremely large. 

As described in Section 6, the client must escape and/or byte stuff 
any Kerberos token bytes, which could be seen as a Telnet environment 
option [RFC1572], specifically VAR, VALUE, ESC, and USERVAR. 


iSeries Telnet server Enhanced Telnet client 
FF FD 27 --> 
<-- FF FB 27 
FF FA 27 01 03 49 42 4D 
52 53 45 45 44 7D 3E 48 
8F 18 08 04 04 00 03 FF 
FO --> 
FF FA 27 00 03 49 42 4D 
54 49 43 48 45 54 01 DF 
BO 40 2F 22 AB A3 BA... 
<-- FF FO 
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7. Device Name Collision Processing 


Device name collision occurs when a Telnet client sends the Telnet 
server a virtual device name that it wants to use, but that device is 
already in use on the server. When this occurs, the Telnet server 
sends a request to the client asking it to try another device name. 
The environment option negotiation uses the USERVAR name of DEVNAME 
to communicate the virtual device name. The following shows how the 
Telnet server will request the Telnet client to send a different 
DEVNAME when device name collision occurs. 


iSeries Telnet server Enhanced Telnet client 


IAC SB NEW-ENVIRON SEND 
VAR USERVAR IAC SE ==> 


Server requests all environment variables be sent. 
IAC SB NEW-ENVIRON IS USERVAR 
"DEVNAME" VALUE "MYDEVICE1" 
USERVAR "xxxxx" VALUE "xxx" 


Saas IAC SE 


Client sends all environment variables, including DEVNAME. Server 
tries to select device MYDEVICE1. If the device is already in use, 


server requests DEVNAME be sent again. 


IAC SB NEW-ENVIRON SEND 
USERVAR "DEVNAME" IAC SE --> 


Server sends a request for a single environment variable: DEVNAME 


IAC SB NEW-ENVIRON IS USERVAR 
<-- "DEVNAME" VALUE "MYDEVICE2" IAC SE 


Client sends one environment variable, calculating a new value of 
MYDEVICE2. If MYDEVICE2 is different from the last request, then 
server tries to select device MYDEVICE2, else server disconnects 
client. If MYDEVICE2 is also in use, server will send DEVNAME 
request again and keep doing so until it receives a device that is 
not in use, or the same device name twice in row. 
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Telnet environment option USERVARs have been defined to allow a 
compliant Telnet client more control over the Telnet server virtual 


device on the iSeries. 


These USERVARS allow the client Telnet to 


select a previously created virtual device or auto-create a new 
virtual device with requested attributes. 


This makes the enhancements available to any Telnet client that 
chooses to support the new negotiations. 


The USERVARsS defined to accomplish this are: 


EXAMPLE 


PRINTER1 

242450 

QSYSOPR 

QSYS 

12 

Cil UNA 

ae li 3 
*TBM42023 

1-byte hex field 
1-byte hex field 
1-byte hex field 
Tlo 

*NONE 

*LIBL 


USERVAR VALUE 

DEVNAME us-ascii char (x) 
IBMIGCFEAT us-ascii char (6) 
IBMMSGQNAME us-ascii char (x) 
IBMMSGQLIB us-ascii char (x) 
IBMFONT us-ascii char (x) 
IBMFORMFEED us-ascii char (1) 
IBMTRANSFORM us-ascii char (1) 
IBMMFRTYPMDL us-ascii char (x) 
IBMPPRSRC1 binary (1) 
IBMPPRSRC2 binary (1) 
IBMENVELOPE binary (1) 
IBMASCII899 us-ascii char(1) 
IBMWSCSTNAME us-ascii char (x) 
IBMWSCSTLIB us-ascii char (x) 
x - up to a maximum of 


10 characters 


DESCRIPTION 

Printer device name 
IGC feature (DBCS) 
*MSGQ name 

*MSGQ library 

Font 

Formfeed 

Transform 

Mfg. type and model 
Paper source 1 
Paper source 2 
Envelope hopper 
ASCII 899 support 
WSCST name 

WSCST library 


The "IBM" prefix on the USERVARs denotes iSeries-specific attributes. 


The DEVNAME USERVAR is used for both displays and printers. 


The 


IBMFONT and IBMASCII899 are used only for SBCS environments. 


For a description of most of these parameters 
the USERVAR) and their permissible values, 


Communications Configuration Reference 


(drop the 
refer to Chapter 8 in the 
[COMM-CONFIG] . 


"TBM" from 


The IBMIGCFEAT supports the following variable DBCS language 


identifiers in position 5 


must be 


Lt 
ret 


Murphy, et 


‘0 


(positions 1-4 must be ’2424’; 


rja 
= Japanese 'K’” = Korean 
Traditional Chinese ‘Ss’ = 
Informational 


al. 


position 6 


Simplified Chinese 
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The IBMTRANSFORM and IBMASCII899 values correspond to: 
‘1’ = Yes '0’ = No 
The IBMFORMFEED values correspond to: 
'C’ = Continuous ‘’U’ = Cut ’A’ = Autocut 
The IBMPPRSRC1, IBMPPRSRC2, and IBMENVELOPE custom USERVARS do not 
map directly to their descriptions in Chapter 8 in the Communications 


Configuration Reference [COMM-CONFIG]. To map these, use the index 
listed here: 


IBMPPRSRC1 HEX IBMPPRSRC2 HEX IBMENVELOPE HEX 
*NONE 'FE’X *NONE '"RPE’X *NONE "FPE’X 
*MFRTYPMDL '00’X *MFRTYPMDL "00’X *MFRTYPMDL "00’X 
*LETTER 101’X *LETTER ToX *BS '06’X 
*LEGAL sa PEED *LEGAL O27 X *MONARCH '09’X 
*EXECUTIVE "03’X *EXECUTIVE '03’X *NUMBERY 'OA’X 
*A4 "O4’X *A4 104'X *NUMBER10 ‘OB’X 
*AS '05'’X *AS '05'’X *E5 '0c’xX 
*BS '06’X *BS '06’X *DL 'OD’X 
*CONT80 'O7'X *CONT80 '0O7’X 
*CONT132 '08’X *CONT132 '08’X 
*A3 'OE’X *A3 'OE’X 
*B4 'OF’X *BA4 'OF’X 
*LEDGER PLO EK *LEDGER fA OMX 
9. Telnet Printer Terminal Types 


New Telnet options are defined for the printer pass-through mode of 
operation. To enable printer pass-through mode, both the client and 
server must agree to support at least the Transmit-Binary, End-Of- 
Record, and Terminal-Type Telnet options. The following are new 
terminal types for printers: 


TERMINAL-TYPE 


IBM-5553-B01 
IBM-3812-1 


DESCRIPTION 
Double-Byte printer 
Single-Byte printer 


Specific characteristics of the IBM-5553-B01 or IBM-3812-1 printers 
are specified through the USERVAR IBMMFRTYPMDL, which specifies the 
manufacturer type and model. 
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An example of a typical negotiation process to establish printer 


pass-through mode of operation is shown below. In this example, the 
server initiates the negotiation by sending the DO TERMINAL-TYPE 
request. 


For DBCS environments, if IBMTRANSFORM is set to 1 (use Host Print 
Transform), then the virtual device created is 3812, not 5553. 
Therefore, IBM-3812-1 (and not IBM-5553-B01) should be negotiated for 
TERMINAL-TYPE. 


iSeries Telnet server Enhanced Telnet client 
IAC DO NEW-ENVIRON --> 
<-- IAC WILL NEW-ENVIRON 
IAC SB NEW-ENVIRON SEND 
VAR USERVAR IAC SE --> 
IAC SB NEW-ENVIRON IS 
USERVAR "DEVNAME" VALUE "PCPRINTER" 
USERVAR "IBMMSGQNAME" VALUE "QSYSOPR" 
USERVAR "“IBMMSGQLIB" VALUE "*LIBL" 
USERVAR "IBMTRANSFORM" VALUE "0" 
USERVAR "IBMFONT" VALUE "12" 
USERVAR “IBMFORMFEED" VALUE "C" 
USERVAR "IBMPPRSRC1" VALUE ESC ’01’X 
USERVAR "IBMPPRSRC2" VALUE '’04’X 
USERVAR "IBMENVELOPE" VALUE IAC ’FEF’X 
<-- IAC SE 
TAC DO TERMINAL-TYPE --> 
<-- TAC WILL TERMINAL-TYPE 


IAC SB TERMINAL-TYPE SEND 


IAC SE --> 
IAC SB TERMINAL-TYPE IS IBM-3812-1 

<-- IAC SE 
IAC DO BINARY --> 

<-- IAC WILL BINARY 
IAC DO EOR --> 

<-- IAC WILL EOR 
Some points about the above example. The IBMPPRSRC1 value requires 
escaping the value using ESC according to Telnet environment options 
[RFC1572]. The IBMPPRSRC2 does not require an ESC character since 
'04’X has no conflict with environment options. Finally, to send 


'FE’X for the IBMENVELOPE value, escape the ’FF’X value by using 
another ’FF’X (called "doubling"), so as not to have the value 
interpreted as a Telnet character per the Telnet protocol 
specification [RFC854]. 
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Actual bytes transmitted in the above example are shown in hex below. 


iSeries Telnet server Enhanced Telnet client 
FF FD 27 --> 

<-- FF FB 27 
FF FA 27 01 00 03 FF FO --> 


FF FD 18 --> 
<-- FF FB 18 
FF FA 18 01 FF FO ==> 


FF FA 18 00 49 42 4D 2D 
<-- 33 38 31 32 2D 31 FF FO 


FF FD 00 --> 
<-- FF FB 00 
FF FD 19 --> 
FF FB 19 
10. Startup Response Record for Printer and Display Devices 


Once Telnet negotiation for a 5250 pass-through mode is completed, 
the iSeries Telnet server will initiate a virtual device (printer or 
display) power-on sequence on behalf of the Telnet client. The 
Telnet server will supply a Startup Response Record to the Telnet 
client with the status of the device power-on sequence, indicating 
success or failure of the virtual device power-on sequence. 


This section shows an example of two Startup Response Records. The 


source device is a type 3812 model 01 printer with the name 
"PCPRINTER" on the target system "TARGET". 


Murphy, et al. Informational [Page 25] 


RFC 4777 IBM’s iSeries Telnet Enhancements November 2006 
Figure 1 shows an example of a successful response; Figure 2 shows an 
example of an error response. 

10.1. Example of a Success Response Record 
The response record in Figure 1 was sent by an iSeries at Release 


V4R2. It is an example of the target sending back a successful 
Startup Response Record. 


foo 5555555555555 555555 555 555 55 555555 nnn + 
+----- Pass-Through header 
| +--- Response data 
| | +---- Start diagnostic information| 
| | 


004912A090000560060020C0003D0000C9F 9FOF2ZE3C1D9ICTC5E34040D7C3D7D9 
| TARGET PCPR 


Response Code (1902) 


C9D5E3C5D9400000000000000000000000000000000000000000000000000000 
INTER 


+------- End of diagnostic information 


Figure 1. Example of a success response record 


- '0049'’X Length pass-through data, including this length field 
-— '12A0'X = GDS LU6.2 header 

— '90000560060020C0003D0000’X = Fixed value fields 

— 'COFOFOF2’X Response Code (1902) 

— 'H3C1D9C7C5E34040’X = System Name (TARGET) 

— 'D7C3D7D9ICID5E3C5D940'X = Object Name (PCPRINTER) 
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10.2. Example of an Error Response Record 


The response record in Figure 2 is one that reports an error. The 
virtual device named "PCPRINTER" is not available on the target 
system "TARGET" because the device is not available. You would 
normally see this error if the printer were already assigned to 
another Telnet session. 


$0555 555555555555 5555 5555 5555555 5 5555555 55555555 + 
+----- Pass-Through header 
| +--- Response data 
| | aa Start diagnostic information| 


| 
004912A09000056006008200003D0000F 8F 9FOF2ZE3C1D9ICTC5SE34040D7C3D7D9 
| TARGET PCPR 


Response Code (8902) 


C9D5E3C5D9400000000000000000000000000000000000000000000000000000 


INTER 
+------- End of diagnostic information 
Pees : 
He ren: 
t----------------- - - - - - 5 5 5 = + 
Figure 2. Example of an error response record 


- '0049’'X = Length pass-through data, including this length field 
-— '12A0'X = GDS LU6.2 header 
— '90000560060020C0003D0000’X = Fixed value fields 


— 'F8F9FOF2’X = Response Code (8902) 
— 'H3C1D9C7C5E34040’X = System Name (TARGET) 
— 'D7C3D7DICID5E3C5D940'X = Object Name (PCPRINTER) 
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10. 


3. Example of a Response Record with Device Name Retry 


The Response Record can be used in conjunction with the DEVNAME 
Environment variable to allow client emulators to inform users of 
connection failures. In addition, this combination could be used by 
client emulators that accept multiple device names to try on session 
connections. The client would be able to walk through a list of 
possible device names and provide feedback based on the response 
code(s) received for each device name that was rejected. 


The following sequence shows a negotiation between the client and the 
server in which a named device "RFCTEST" is requested by the client. 
The device name is already assigned to an existing condition. The 
server responds with the Response Record showing an 8902 response 
code. The client could use this information to inform the user that 
the device name just tried was already in use. Following the 
Response Record the server would then invite the client to try 
another device name. Because the same device name was used again by 
the client, the server closed the session. 
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iSeries Telnet server 

TAC DO NEW-ENVIRON 
IAC DO TERMINAL-TYPE 

IAC SB NEW-ENVIRON SEND 


USERVAR "IBMRSEEDXXXXXXXX" 
VAR USERVAR IAC SE 


IAC SB TERMINAL-TYPE SEND 
IAC SE 


IAC DO EOR 

IAC WILL EOR 

IAC DO BINARY 

IAC WILL BINARY 

(73 BYTE RFC 1205 RECORD 
WITH 8902 ERROR CODE) 
IAC SB NEW-ENVIRON SEND 


USERVAR "DEVNAME" 
IAC SE 


(server closes connection) 


et al. 


iSeries Telnet Enhancements 


Informational 


Enhanced Telnet client 


IAC WILL NEW-ENVIRON 


IAC WILL TERMINAL-TYPE 


IAC SB NEW-ENVIRON IS 
USERVAR "DEVNAME" 

VALUE "RFCTEST" 

USERVAR "IBMSENDCONFREC" 
VALUE "YES" 

IAC SE 


IAC SB TERMINAL-TYPE IS 
IBM-3180-2 IAC SE 

(terminal type negotiations 
completed) 


IAC WILL EOR 
IAC DO EOR 
IAC WILL BINARY 


IAC DO BINARY 


IAC SB NEW-ENVIRON IS 
USERVAR "DEVNAME" 

VALUE "RFCTEST" 

USERVAR "IBMSENDCONFREC" 
VALUE "YES" 

IAC SE 


November 2006 
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Actual bytes transmitted in the above example are shown in hex below. 


iSeries Telnet server 


z] 
nj 


FA 


zI 
Hy 


FD 


z] 
Hy 


FB 


T] 
hy 


FD 


z] 
Hy 


FB 


00 49 
06 00 
F8 F9 
F5 40 
00 00 
00 00 
00 00 
00 00 
00 00 
00 FF 
FF FA 
4E 41 


18 


19 


19 


00 


00 


12 
20 
FO 
40 
00 
00 
00 
00 
00 
EF 
27 
4D 


01 
45 
E3 


o1 


AO 
co 
F2 
40 
00 
00 
00 
00 
00 


01 
45 
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03 
44 
34 


FF 


90 
00 
D9 
00 
00 
00 
00 
00 
00 


03 
FF 


49 42 4D 


C4 96 67 


00 03 FF 


FO 


00 
3D 
E2 
00 
00 
00 
00 
00 
00 


44 
FO 


05 
00 
FO 
00 
00 
00 
00 
00 
00 


45 


60 
00 
F3 
00 
00 
00 
00 
00 
00 


56 


Enhanced Telnet client 


--> 

<-—-— FF FB 

--> 

<--— FF FB 

--> 
FF FA 
4E 41 
54 45 
53 45 
52 45 

<-- FO 

--> 

<-—-— FF FA 
33: 31 

--> 

<-—-— FF FB 

--> 

<--— FF FD 

--> 

<--— FF FB 

--> 

<--— FF FD 

--> 

--> 

<-—-— FF FA 
4E 41 
54 45 
53 45 
52 45 
FO 

Informational 


27 
4D 
53 
4E 
43 


18 


38 


129 


19 


00 


00 


27 
4D 
53 
4E 
43 


00 
45 
54 
44 
01 


00 
30 


00 
45 
54 
44 
01 


03 
01 
03 
43 
59 


49 
2D 


03 
01 
03 
43 
59 


44 
52 
49 
4F 
45 


42 
32 


44 
52 
49 
4F 
45 


45 
46 
42 
4E 
53 


4D 
FF 


45 
46 
42 
4E 
53 


56 
43 
4D 
46 
FF 


2D 
FO 


56 
43 
4D 
46 
FF 
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10.4. Response Codes 


The Start-Up Response Record success response codes: 


CODE DESCRIPTION 

T1901 Virtual device has less function than source device. 

1902 Session successfully started. 

1906 Automatic sign-on requested, but not allowed. 
Session still allowed; a sign-on screen will be 
coming. 


The Start-Up Response Record error response codes: 


CODE DESCRIPTION 

2702 Device description not found. 

2703 Controller description not found. 
2777 Damaged device description. 

8901 Device not varied on. 

8902 Device not available. 

8903 Device not valid for session. 

8906 Session initiation failed. 

8907 Session failure. 

8910 Controller not valid for session. 
8916 No matching device found. 

8917 Not authorized to object. 

8918 Job canceled. 

8920 Object partially damaged. 

8921 Communications error. 

8922 Negative response received. 

8923 Start-up record built incorrectly. 
8925 Creation of device failed. 

8928 Change of device failed. 

8929 Vary on or vary off failed. 

8930 Message queue does not exist. 

8934 Start-up for S/36 WSF received. 

8935 Session rejected. 

8936 Security failure on session attempt. 
8937 Automatic sign-on rejected. 

8940 Automatic configuration failed or not allowed. 
1904 Source system at incompatible release. 
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The Start-Up Response Record error response codes for non-Kerberos 
Services Token automatic sign-on: 


CODE 
0001 
0002 
0003 
0004 
0005 
0006 
0008 


DESCRIPTION 

System error. 

Userid unknown. 

Userid disabled. 

Invalid password/passphrase/token. 
Password/passphrase/token is expired. 

Pre-V2R2 password. 

Next invalid password/passphrase/token will revoke userid. 


The Start-Up Response Record error response codes for Kerberos 
Services Token automatic sign-on support: 


CODE 
0001 
0002 
0003 
0004 
0005 
0006 


1000 


2000 
6000 
7000 


9000 
A000 
B000 
D000 


DESCRIPTION 

User profile is disabled. 

Kerberos principal maps to a system user profile. 
Enterprise Identity Map (EIM) configuration error. 

EIM does not map Kerberos principal to user profile. 

EIM maps Kerberos principal to multiple user profiles. 
EIM maps Kerberos principal to user profile not found on 
system. 

None of the requested mechanisms are supported by the 
local system. 

The input name is not formatted properly or is not valid. 
The received input token contains an incorrect signature. 
No credentials available or credentials valid for context 
init only. 

Consistency checks performed on the input token failed. 
Consistency checks on the cred structure failed. 
Credentials are no longer valid. 

The runtime failed for reasons that are not defined at the 
GSS level. 


In the case where the USERVAR, DEVNAME USERVAR, IBMSENDCONFREC 


USERVAR, IBMSUBSPW USERVAR, and IBMRSEED USERVAR are all used 
together, any device errors will take precedence over automatic 
sign-on errors. That is: 


1) If the requested named device is not available or an error occurs 


when 


attempting to create the device on the server system, a 


device related return code (i.e., 8902) will be sent to the client 
system in the display confirmation record. 
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2) If the requested named device is available or no errors occur when 
attempting to create the device on the server system, an automatic 
sign-on return code (i.e., 0002) will be sent to the client system 
in the display confirmation record. 

11. Printer Steady-State Pass-Through Interface 


The information in this section applies to the pass-through session 
after the receipt of startup confirmation records is complete. 


Following is the printer header interface used by Telnet. 


+-- Length of structure (LLLL) 

+-- GDS identifier 

+-- Data flow record 

+-- Length of pass-through specific header (LL) 
+-- Flags 

+-- Printer operation code 


+-- Diagnostic field - zero pad to 
| LL specified 


| 
| 
| 
| | +-- Printer data 
| 


+--+ +--+ +--+ ++ +--+ ++ +---------- + +---------------- + 


XXXX 12A0 XXXX XX XXXX XX XXXXXXXXXXXX ... print data 


Figure 3. Layout of the printer pass-through header 


BYTES 0-1: Length of structure including this field (LLLL) 
BYTES 2-3: GDS Identifier (’12A0’X) 
BYTE 4-5: Data flow record 


This field contains flags that describe what type of 
data pass-through should be expected to be found 
following this header. Generally, bits 0-2 in the first 
byte are mutually exclusive (that is, if one of them is 
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set to ‘'1’B, the rest will be set to ’0’B.) The bits and 
their meanings follow. 


BIT DESCRIPTION 


Start-Up confirmation 
Termination record 

Start-Up Record 

Diagnostic information included 


PrROoOANAAWNERO 
l 
ol 


Reserved 
Reserved 
Printer record 
= 13 Reserved 
4 Client-originated (inbound) printer record 
5 Server-originated (outbound) printer record 
BYTE 6: Length printer pass-through header including this field 
(LL) 
BYTES 7-8: Flags 


BYTE 7 BITS: xxxx x111 --> Reserved 


xxxx lxxx --> Last of chain 
xxxl xxxx --> First of chain 
xx1lx xxxx --> Printer now ready 
x1lxx xxxx --> Intervention Required 
1xxx xxxx --> Error Indicator 
BYTE 8 BITS: xxxx xxxx --> Reserved 
BYTE 9: Printer operation code 


‘01’X Print/Print complete 
'02’'X Clear Print Buffers 


BYTE 10-LL: Diagnostic information (Note 1) 


If BYTE 7 = xxlx xxxx, then bytes 10-LL may contain: 
Printer ready c9 00 00 00 02 


If BYTE 7 = xlxx xxxx, then bytes 10-LL may contain: (Note 2) 
Command/parameter not valid C9 00 03 02 2x 


Print check c9 00 03 02 3x 
Forms check c9 00 03 02 4x 
Normal periodic condition C9 00 03 02 5x 
Data stream error c9 00 03 02 6x 


Machine/print/ribbon check C9 00 03 02 8x 
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If BYTE 7 = 1xxx xxxx, then bytes 10-LL may contain: (Note 3) 


Cancel 08 11 02 00 
Invalid print parameter 08 11 02 29 
Invalid print command 08 11 02 28 


Diagnostic information notes: 


1. LL is the length of the structure defined in Byte 6. If no 
additional data is present, the remainder of the structure must 
be padded with zeroes. 


2. These are printer SIGNAL commands. Further information on these 
commands may be obtained from the 5494 Remote Control Unit 
Functions Reference guide [5494-CU]. Refer to your iSeries 
printer documentation for more specific information on these data 
stream exceptions. The following are some 3812 and 5553 errors 
that may be seen: 


Machine check c9 00 03 02 11 
Graphics check C9 00 03 02 26 
Print check C900 403". 02:° 3.1 
Form jam c9 00 03 02 41 
Paper jam C9 00 03 02 47 
End of forms c9 00 03 02 50 
Printer not ready C9- 00 03: 02 51 
Data stream - class 1 C9 00 03 02 66 loss of text 
Data stream - class 2 C9 00 03 02 67 text appearance 
Data stream - class 3 C9 00 03 02 68 multibyte control error 
Data stream - class 4 C9 00 03 02 69 multibyte control parm 
Cover unexpectedly open c9 00 03 02 81 
Machine check C9 00 03 02 86 
Machine check C9 00 03 02 87 
Ribbon check C9 00 03 02 88 
3. These are printer negative responses. Further information on 


these commands may be obtained from the 5494 Remote Control Unit 
Functions Reference guide [5494-CU]. 


The print data will start in byte LL+1. 
11.1. Example of a Print Record 
Figure 4 shows the server sending the client data with a print 


record. This is normally seen following receipt of a Success 
Response Record, such as the example in Figure 1. 


Murphy, et al. Informational [Page 35] 


RFC 4777 IBM’s iSeries Telnet Enhancements November 2006 


+-- Length of structure (LLLL) | 

+-- GDS identifier | 
| +-- Data flow record 

| +-- Length of pass-through specific header (LL) | 

| | +-- Flags | 

| 

| 


| | | | +-- Zero pad to LL specified (0A) 
+-- Printer data 


+--+ +--+ +--+ ++ +--+ ++ 4---------- + $--------------------------- 


0085 12A0 0101 OA 1800 01 000000000000 34C4012BD20345FF2BD2044C0002 | 


| 
| 
| | | | +-- Printer operation code 
| 


2BD10705000B0090012BD2044900F02BD206404A403DE02BD2041500F034 


end of printer data 


4+--------------------------- -- - - - - - 5 5 ee + 
Figure 4. Server sending client data with a print record 

- '0085’xX = Logical record length, including this byte (LLLL) 

— '12A0'X = GDS LU6.2 header 

- '0101’X = Data flow record (server to client) 

- 'OA’X = Length of pass-through specific header (LL) 

- '1800’X = First of chain / Last of chain indicators 

se 01 = Print 

-— '000000000000’X = Zero pad header to LL specified 

= '34C401’X = First piece of data for spooled data 


- Remainder is printer data/commands/orders 
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11.2. Example of a Print Complete Record 


November 2006 


Figure 5 shows the client sending the server a print complete record. 
This would normally follow receipt of a print record, such as the 


example in Figure 4. 


request. 


+--+ +--+ +- 


000A 12A0 01 


Figure 5 


- '0Q00A’X = Logical record length, 


- '12A0’X = GD 


- '0102’X = Data flow response record 


+-- Length of structure (LLLL) 
+-- GDS identifier 


+-- Data flow record 


| +-- Length of pass-through specific header (LL) 


| | +-- Flags 


| +-- Printer operation code 


| | 
Wd sl 
-+ ++ +--+ ++ 


02 04 0000 01 


This indicates successful completion of a print 


. Client sending server a print complete record 


S LU6.2 header 


- '04'X = Length of pass-through specific header 


- '0000’X = Go 
= QT FX = Pr 


11.3. Example of 
Figure 6 shows 


The null print 
the client for 


od Response 
int Complete 


a Null Print Record 
the server sending the client a null 


record is the last print command the 
a print job, and it indicates to the 


there is no more data. The null data byte ’00’X is 


some cases may 


including this byte (LLLL) 


(client to server) 
(LL) 


print record. 
server sends to 
printer that 
optional and in 


be omitted (in particular, this scenario occurs in 
DBCS print streams). 


This example would normally follow any number of print records, such 
in Figure 4. This indicates successful completion of 


as the example 
a print job. 


Murphy, et al. 


Informational 


The client normally responds to this null print record 


with another print complete record, such as in Figure 5. 
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+-- Length of structure (LLLL) 

+-- GDS identifier 

| +-- Data flow record 

| | | +-- Length of pass-through specific header (LL) 
| | | | +-- Flags 

| | | | | +-- Printer operation code 

| | | | | | +-- Zero pad to LL specified (0A) 
| | | | +-- Printer data 


+--+ +--+ +--+ ++ +--+ ++ 4---------- + ++ 


0011 12A0 0101 0A 0800 01 000000000000 00 


4+--------------------------- - - - - 5 ee + 
Figure 6. Server sending client a null print record 

- '0011’X = Logical record length, including this byte 

— '12A0'X = GDS LU6.2 header 

= FQ101"X = Data flow record 

- 'OA’X = Length of pass-through specific header (LL) 

- '0800’X = Last of Chain 

= EOLEX = Print 

—- '000000000000’X = Zero pad header to LL specified 

- '00’X = Null data byte 
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The next example shows a full print exchange between a Telnet client 


and server for a 526 byte spooled file. 
Telnet negotiations and 2) 
Telnet negotiations are 
ASCII/EBCDIC 


hexadecimal streams into 1) 


characters is done to aid readability. 
parenthesis characters; 


delimited by ’(’ and 


oD ad 


Selective translation of the 


ASCII/EBCDIC 


conversions are bracketed by ’|’ vertical bar characters. 


iSeries Telnet server 


FFFD27 


(IAC DO NEW-ENVIRON) 


FFFDI8FFFA270103 49424D5253454544 
7EASDFDDFD300404 O003FFFO --> 


(IAC DO TERMINAL-TYPE 
IAC SB NEW-ENVIRON SEND USERVAR 


IBMRSEED xxxxxxxx VAR USERVAR 
IAC SE) 


FFFA1801FFFO 


(IAC SB TERMINAL-TYPE SEND IAC 
SE) 


<-- 


et al. 


Enhanced Telnet client 


FFFB27 


(IAC WILL NEW-ENVIRON) 


FFFB18 


(IAC WILL TERMINAL-TYPE) 


FFFA27000349424D 
DDFD300404000344 
554D4D5950525403 
414D450151535953 
5347514C4942012A 
464F4E5401313103 
464F524D01310349 
4D444C012A485049 
5352433101020103 
433201040349424D 
O1FFFF0349424D41 
30FFFO 


Informational 


52534545447EA5DF 
45564E414D450144 
49424D4D5347514E 
4F50520349424D4D 
4C49424C0349424D 
49424D5452414E53 
424D4D4652545950 
490349424D505052 
49424D5050525352 
454E56454C4F5045 
5343494938393901 
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(IAC SB NEW-ENVIRON IS USERVAR 
IBMRSEED XXXXXXXX VAR 
USERVAR DEVNAME VALUE DUMMYPRT 
USERVAR IBMMSGQNAME VALUE 
OSYSOPR 
USERVAR I 
USERVAR I 
I 


BMMSGQLIB VALUE *LIBL 

BMFONT VALUE 11 
USERVAR IBMTRANSFORM VALUE 1 
USERVAR IBMMFRTYPMDL VALUE *HPII 
USERVAR IBMPPRSRC1 VALUE 
ESC ’01’X 
USERVAR IBMPPRSRC2 VALUE ’04’X 
USERVAR IBMENVELOPE VALUE IAC 
USERVAR IBMASCII899 VALUE 0 
IAC SE) 


<-- FFFA180049424D2D 333831322D31FFFO 


(IAC SB TERMINAL-TYPE IS 
IBM-3812-1 IAC SE) 


FFFD19 zis 
(IAC DO EOR) 
<-- FFFB19 
(IAC WILL EOR) 
FFFB19 Seis 


(IAC WILL EOR) 


<-- FFFD19 
(IAC DO EOR) 
FFFDOO --> 
(IAC DO BINARY) 
<-- FFFBOO 


(IAC WILL BINARY) 
FFFBOO --> 


(IAC WILL BINARY) 
<-- FFFDO0O 


(IAC DO BINARY) 
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004912A090000560 060020C0003D0000 | a { 
C9F9FOF2C5D3C3D9 E3D7FOF6C4E4D4D4 | 1902ELCRTPO6DUMM | (EBCDIC) 
E8D7D9E340400000 0000000000000000 Ree 
0000000000000000 0000000000000000 
0000000000000000 OOFFEF --> | 
(73-byte startup success response 

record IAC EOR) 
OODF12A001010A18 0001000000000000 | 
03CD1B451B283130 551B287330703130 E (10U (s0p10| (ASCII) 
2E30306831327630 733062303033541B |. 00h12v0s0b003T | 
287330421B266440 1B266C304F1B266C |(sOB &d@ &100 &1| 
303038431B266C30 3035431B28733070 lodec &1005C (sOp| 
31372E3130683130 7630733062303030 e on 
541B283130551B28 73307031372E3130 |T (10U (s0p17.10| 
6831307630733062 303030541B287330 ee (sO 
421B2664401B266C 314F1B266C303035 B &d@ &110 &1005 
431B287330703137 2E31306831307630 |C (s0p17.10h10v0 | 
733062303030541B 266C314F1B287330 |sObOOOT &110 (s0| 
7031372E31306831 3076307330623030 |p17.10h10v0s0b00 | 
30541B2873307031 372E313068313076 [OT (sO0p17.10h10v| 
3073306230303054 1B266C30303543FF OsObO00T &1005C | 
EF ay 
(... 223-byte print record 
first of chain 
last of chain IAC EOR) 
<-- 000A12A001020400 0001FFEF 
(10-byte print complete header) 
031012A001010A10 0001000000000000 | 
O3FFFF1B451B2831 30551B2873307031 | E (10U (s0p1| (ASCII) 
372E313068313076 3073306230303054 |7.10h10v0s0b000T | 
1B287330421B2664 401B266C314F1B26 | (sOB &d@ &110 =| 
6C303035431B266C 31481B266C314F1B 1005C &11H &110 
266C3032411B266C 31431B266C303030 |&102A &11C &1000| 
38451B266C303038 431B266C30303439 |8E &1008C &10049| 
461B266130521B26 6C303035430A0A0A |F &a0R &1005C | 
0A0A0A0A1B26612B 3030303130561B26 | &a+00010V &| 
6C303035431B2661 2B30303231364820 i &a+00216H | 
2020202020202020 2020202020202020 
2020202020205072 696E74204B657920 | Print Key | 
4F75747075742020 2020202020202020 |Output 
2020202020202020 2020202020202020 | 
2020202020205061 6765202020310D0A | Page || 
1B26612B30303231 3648202020203537 | &a+00216H 
3639535331205634 52334D3020393830 69SS1 V4R3M0 a6 
373203FFFF392020 2020202020202020 |72 9 
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202020202020454C 
2020202020202020 
3939202031363A33 
612B303032313648 
3231364820202020 
4465766963652020 
2E203A2020515041 
0A1B26612B303032 
73657220202E202E 
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4352545030362020 
202030332F33312F 
303A34350D0A1B26 
OD0A1B26612B3030 
446973706C617920 
2E202E202E202E20 
444556303033510D 
3136482020202055 
202E202E202E202E 


202E202E202E202E 
54524F0D0A1B2661 
0A1B26612B303032 
2020202020202020 
2020202020202020 
30204D61696E204D 
2B30303203FFFF31 
2020202020202020 
2020202020202020 
2020202020202020 
2020202020202053 
20454C4352545030 
3032313648205365 
206F 662074686520 
673A0D0A1B26612B 
1B26612B30303231 
312E205573657220 
26612B3030323136 
2E204F 6666696365 
1B26612B30303231 
3030323136482020 
696C65732C206C69 
20616EFFEF 


(... 784-byte pr 


first of chain 


020312A001010A00 
64206603FFFFO6F6C 
612B303032313648 
3231364820202020 
6D756E6963617469 
2B3030323136480D 
3136482020202020 
6C656D2068616F64 
612B303032313648 


et al. 


203A202052434153 
2B3030323136480D 
313648204D41494E 
2020202020202020 
20202041532F3430 
656E750D0A1B2661 
3648202020202020 
2020202020202020 
2020202020202020 
2020202020202020 
797374656D3A2020 
360D0A1B26612B30 
6C656374206F6E65 
666F 6COC6F77696E 
3030323136480D0A 
3648202020202020 
7461736B730D0A1B 
4820202020202032 
207461736B730D0A 
36480D0A1B26612B 
20202020342E2046 
627261726965732C 


int record 


| ELCRTP06 

| 03/31/| 
99 16:30:45 & 
a+00216H | 
|216H Display 
|Device ; ; 
E QPADEV0030 
| &a+00216H 

ser 


"RCAS 
TRO &a+00216H 
&a+00216H MAIN 


| 
| 
| 
as 
| 
| 


| 
| 
| 
| 
|o Main Menu 
+002 


AS/40| 
&a| 
16H | 


| 

| 

System: | 
ELCRTPO6  &a+0| 
0216H Select one 
of the followin 
|g:  &a+00216H | 
| &a+00216H | 
| 

| 


|1. User tasks 

|&a+00216H 2 
. Office tasks 
| &a+00216H &at 
|00216H F| 
|iles, libraries, | 
| an | 


November 2006 


IAC EOR) 
<-- 000A12A001020400 OOO1FFEF 
(10-byte print complete header) 
0001000000000000 
646572730D0A1B26 df olders &| (ASCII) 
O0D0A1B26612B3030 |a+00216H &a+00| 
2020362E20436F6D |216H 6. Com| 
6F 6E730D0A1B2661 [munications &a| 
0A1B26612B303032 |+00216H &at+002| 
20382E2050726F62 16H 8. Prob 
6C696E670D0A1B26 lem handling & 
202020202020392E |a+00216H 9. | 
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20446973706C6179 
0A1B26612B303032 
31302E20496E666F 
417373697374616E 
730D0A1B26612B30 
202031312E20436C 
6573732F34303020 
26612B3030323136 
303231364803ED20 
5369676E206F 6666 
323136480D0A1B26 
2053656C65637469 
6D6D616E640D0A1B 
48203D3D3D3E0OD0A 
36480D0A1B26612B 
333D457869742020 
707420202046393D 
2020204631323D43 
4631333D496E666F 
417373697374616E 
3032313648204632 
697469616C206D65 
3030323136480D0A 
36480D0CFFEF 


(... 515-byte pr 
IAC EOR) 


001412A001010A00 
03021 B45FFEF 
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2061206D656E750D 
3136482020202020 
726D6174696F 6E20 
74206F7074696F6E 
3032313648202020 
69656E7420416363 
7461736B730D0A1B 
480D0A1B26612B30 
2020202039302E20 
OD0A1B26612B3030 
612B303032313648 
6F6E206F 722063 6F 
26612B3030323136 
1B26612B30303231 
3030323136482046 
2046343D50726F 6D 
5265747269657665 
616E63656C202020 
726D6174696F 6E20 
740D0A1B26612B30 
333D53657420696E 
6E750D0A1B26612B 
1B26612B30303231 


int record 


(... 20-byte print record 


IAC EOR) 


001112A001010A08 
OOFFEF 


(... 17-byte NULL print record 


last of cha 


et al. 


| Display a menu | 
| &a+00216H | 
10. Information 
Assistant option 
|s &a+00216H_ | 
| 11. Client Acc| 
|ess/400 tasks | 
|&a+00216H &a+0| 
0216H 90. | 
Sign off &at+00 
|216H &a+00216H| 
| Selection or co| 
|mmand é&a+00216| 
|H ===> §at0021| 
[6H &at+00216H F| 
me F4=Prom 
pt F9=Retrieve 
| F12=Cancel 
|F13=Information | 
[Assistant &a+0| 
|0216H F23=Set in| 
itial menu &at 
00216H &a+0021 
| 6H | 
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<-- 000A12A001020400 OOOLFFEF 
(10-byte print complete header) 
0001000000000000 | | 
| E | (ASCII) 
<-- 000A12A001020400 OOOLFFEF 
(10-byte print complete header) 
0001000000000000 
--> 
in IAC EOR) 
<-- 000A12A001020400 OOO1LFFEF 
(10-byte print complete header) 
Informational 
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13. Security Considerations 


The auto-sign-on feature provided by this RFC describes a way to 
encrypt your login password. However, while passwords can now be 
encrypted by using the IBMRSEED and IBMSUBSPW USERVAR negotiations, 
users should understand that only the login passwords are encrypted 
and not the entire Telnet session. Encryption of the Telnet session 
requires that another protocol layer, such as SSL, be added. 


The auto-sign-on feature supports plain text passwords, encrypted 
passwords, and Kerberos tokens. However, using plain text passwords 
is strongly discouraged. iSeries system administrators may want to 
configure their systems to reject plain text passwords. 

14. IANA Considerations 
IANA registered the terminal types "IBM-3812-1" and "IBM-5553-B01" as 
a terminal type [RFC1091]. They are used when communicating with 
iSeries Telnet servers. 
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